1. Field of the Invention
The present invention generally relates to a system and method for server migration synchronization within a software development process, and more particularly to a system and method for managing the migration of software components among servers that form a distributed software test environment.
2. Related Art
It is very common for a business enterprise that has used a given software application for some length of time to determine that it needs to modify the software, for any of a number of reasons. For example, the enterprise may need to enable the application to exchange data with another application, or wish to improve the quality, speed or ease-of-use of the user interfaces provided by the application, or to add altogether new capabilities to the application, etc. Where the application exists in a distributed software environment, as is the case with a tremendous amount of software in enterprises of any size, there is a consequent need to establish a well-defined software development process to ensure that the process of developing and testing the software improvements is conducted in an orderly fashion.
One approach is to adopt some form of versioning control of source code. This approach has been used reasonably satisfactorily in some instances, but its effectiveness is greatest where the software in question exists only on one computer, and dwindles quickly if used with distributed software. Especially when software resides in multiple servers, therefore, a migration plan is needed to manage the process of modifying software and of migrating the modifications from a test environment to a production environment. (By “production environment” is meant the environment in which the application will be in actual use as opposed to mere testing, and in particular the environment in which the application must function properly, and without unexpected problems that might interfere with the users of the application in their conduct of the enterprise's business).
In the development of a software enhancement, the development team may involve a relatively large number of people, who may not all work in the same place, or even in the same time zone. It is all too easy for one portion of such a team to make a modification to the software under development without the rest of the team being aware of what has been done. For example, without some form of versioning control, software components that are of a version different than a production version could exist simultaneously in plural test servers, causing errors and discrepancies during testing.
In addition, the potential is great for inconsistent modifications to be made, or that two portions of the team may both write modifications to one portion of the software, with both sets of modifications needing to be adopted in the final version. For example, a component being modified by one test team (call their work “job 1”) and simultaneously by a second team (call their work “job 2”) could result in the modifications by job 1 being rolled into production and then overwritten by job 2 when job 2 is rolled into production, with the result that the modifications made by job 1 would be lost. Therefore, there is a need to ensure that the changes to the component by job 1 are included in the changes to the component by job 2 and vice versa in such situations.
Moreover, if a given module or other component of an application is modified, then in testing the modified software it is important that the other software with which that modified portion interacts, is identical to what is used throughout the enterprise. If the test is conducted on a server where an outdated version of one relevant program is used, for example, various problems are apt to result. First, of course, since the modification will be intended to interact with the current version, the presence of the older version in the test server may produce errors or discrepancies in operation that would not occur with the current version, thus producing misleading test results, and requiring additional time in identifying the problem, and thus increasing the overall time required to have the modified component(s) ready to be introduced throughout the enterprise.
Conversely, the older version in the test server may actually interact well with the modified software where the current version would not, thus causing the test team to miss a problem until the modified software is eventually used with the current version of the other program. Since an occurrence of this sort may not be recognized until the modified software has been introduced into production, the resulting problems could be relatively serious ones in terms of their effect on the enterprise's efficiency.
Thus, it is also important to ensure that a new modification of software is tested in an environment that accurately represents the environment in which the modification will ultimately be used once it is approved.
Also, once a module or other component of the new software has been released for use by the enterprise (i.e., is no longer regarded as being in testing), it would be highly undesirable for a portion of the development team that for some reason had not been notified, or had not understood, that that component was no longer in testing, to continue writing modifications to that component, with consequent possible confusion.
Thus, multiple challenges are presented when managing the migration of software components during the software development process, and these challenges are greater when the software is developed and tested in a distributed test environment including a plurality of test servers and test teams.
For all these reasons, these development teams developing and testing software components need a reliable method for managing the migration of tested software components from the test environment to the production environment.
Accordingly, there is a need, not fulfilled by current versioning control tools, to ensure that the software components in each of plural test servers represent the production version except for the software components being tested.
Given the foregoing, what is needed is a system, method and computer program product for server migration synchronization.